CHECK BASED ONLINE PAYMENT AND VERIFICATION SYSTEM 

AND METHOD 



RELATED APPLICATIONS 

This application is related to application 09/859,356, filed May 18, 2001, 
entitled "Check Authorization System and Method", and application 09/901,124, 
filed July 10, 2001, entitled "Check Authorization System and Method, by the 
same inventors as this application. The contents of those related applications are 
incorporated in their entirety herein by reference. 

BACKGROUND OF THE INVENTION 

A. FIELD OF THE INVENTION 

[0001] The invention relates generally to a check based online payment and 
verification system and method, and more particularly, to a check based online 
payment and verification system and method for utilizing checks for paying for 
transactions performed on the Internet. 

B. DESCRIPTION OF THE RELATED ART 

[00021 Check authorization and check verification systems and methods are 
becoming more and more important, since check fraud amounts to billions of 
dollars lost per year by banks and retail establishments. One such check 



authorization system is described in U.S. Patent No. 6,170,744, by Warren S. 
Lee and William Meadow, which is assigned to Payformance Corporation and 
which is incorporated in its entirety herein by reference. In the system and 
method described in U.S. Patent No. 6,170,744, information is provided on a 
check by way of a bar code provided on the check, whereby that information is 
used to verify the check's authenticity. 

10003] Such a system requires that the bar code be placed on a portion of the 
check that is not reserved for other purposes. 

[0004] Additionally, check based authorization and verification systems are 
needed for the increasing amount of transactions consummated on the Internet. 
Currently, the preferred method of payment is via credit card. However, use of 
credit cards is not particularly good for merchants, since the credit card 
companies typically take a 3% to 6% fee per transaction. Thus, if a customer 
buys a $100 item from a merchant, the merchant would only clear $94 after 
paying the credit card company a 6% fee ($6.00) for the customer's use of a 
credit card to pay for the transaction. If instead the customer paid cash or used a 
check, the merchant would not have to pay this overhead to the credit card 
companies. 



[0005] Banks also prefer the use of checks instead of other modes of payment, due 
to their being able to make money off of the "float" of checks as the checks are 
processed through the Automated Clearing House (ACH) system (which may 
take several days to complete). 

[00061 The check authentication described in U.S. Patent No. 6,170,744 is made 
by physically scanning the check itself, such as by using a bar code scanner to 
scan the bar code on the check, in order to obtain the information from the bar 
code. Thus, authorization or verification of the check at a location different from 
the point-of-sale location, such as by a web server of a merchant accessible over 
the Internet, is difficult if not impossible to accomplish utilizing such a scheme. 
[0007] Accordingly, it is desired to come up with a system and method for using 
checks as a mode of payment, for transactions performed over the Internet. 

SUMMARY OF THE INVENTION 
[0008] The present invention is directed to a method of verifying a check that is 
being used for an on-line transaction. The method includes a step of entering in, 
by a customer using a computer, data obtained from a MICR line of the check, 
the data including a one-way hash value that is based on the data provided on the 
MICR line as well as private data not provided on the MICR line. The method 
also includes a step of receiving, by a web server of a merchant for which the 
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customer seeks to make the on-line transaction, the data entered by the customer, 
the data being received by way of a computer network. The method further 
includes a step of transmitting, by the web server of the merchant to a check 
verifier, the data entered by the customer. The method still further includes a 
step of verifying, by the check verifier, whether or not the check is valid. The 
verifying is performed by computing a hash value based on the data entered by 
the customer, as well as private data of the customer that is obtained from a 
database accessible by the check verifier. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[00091 The foregoing advantages and feamres of the invention will become 

apparent upon reference to the following detailed description and the 

accompanying drawings, of which: 

[0010] Figure 1 is a diagram of a standard MICR line on a check; 

10011] Figure 2A is a diagram of a MICR line that includes a hash code and that 

is printed on a check according to a first embodiment of the invention; 

[0012] Figure 2B is a diagram of a MICR line that includes a hash code and a 

product code tiiat are printed on a check according to a second embodiment of the 

invention; 
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[00131 Figure 3 is a block diagram of the elements utilized in creating a check, 
according to any of the embodiments of the invention; 

[00141 Figure 4 shows the elements utilized in generating and transmitting a key 
to be used in the generation of a hash value, according to the third embodiment 
of the invention; 

[0015] Figure 5 is a flow chart describing the process for computing a hash value 
to be printed on each check, according to any of the embodiments of the 
invention; 

[0018] Figure 6 is a block diagram of the entities involved in a check verification 
process, according to any of the embodiments of the invention; 
[0017] Figure 7 is a block diagram of the entities involved in a check verification 
process from the perspective of a check verifier service provider, according to 
any of the embodiments of the invention; 

[0018] Figure 8 shows an insert card that may be used for checks without hash 
values printed thereon, according to any of the embodiments of the invention; 
and 

[0019] Figure 9 shows a template that may be used by a customer to read and then 
enter, via a computer keyboard or the like, data to be sent over the Internet, 
according to any of the embodiments of the invention. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0020] Preferred embodiments of the invention will be described in detail below, 

with reference to the accompanying drawings. 

[0021] The present invention provides a check based online payment and 
verification system and method, for use for transactions made over die Internet, 
for example, whereby payment by check is an accepted mode of payment by a 
merchant conducting business over the Internet (such a merchant is also called an 
"e-tailer" below). 

[0022] The present invention helps detect the use of unauthorized or unverified 
checks for purchasing goods or services over the Internet or some other type of 
computer network. The present invention maintains a list of check numbers 
which have been presented for payment and hence prevents the reuse of check 
numbers. The present invention helps lessen the costs for e-tailers, banks and/or 
check verification services associated with improperly verifying checks, whereby 
the dollar amount lost by improperly verifying checks would have to be covered 
by the retail establishments and/or by banks and/or check verification services 
that made the improper verification. 

[0023] The present invention provides for processing each check submitted for 
verification, and provides for verification of each check presented for an on-line 
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purchase. In order to accomplish this, a one-way hash value is computed in 
order to obtain an enhanced level of security. The one-way hash value is 
preferably written onto the MICR line of the check as an n-digit value, when the 
check is created by a check printing service. The one-way hash value is 
computed based on input data which includes: 1) customer-specific information, 
and 2) a key that has been encrypted by a bank or other provider of the key, 
whereby the key provides an additional level of authentication and fraud 
deterrence. The key and the encryption of the key are optional features that are a 
part of the third embodiment described below, and are not part of the first and 
second embodiments described below. 

[0024] Figure 1 shows the format of a MICR line 110 on a standard check. The 
MICR line is used by banks for check clearance processing. The information 
provided on the MICR line and the positioning of that information on a check is 
based on well known specifications MICR specifications. See, for example, 
Standards for MICR Encoded Documents, Standard 006, obtained from 
www . cdnpay . ca/eng/rules/006 . ENG2 . htm#2 . 20 . 

[0025] For a personal check, the MICR line provides information corresponding 
to: 1) the ABA number of the bank at which die check is to be debited against 
(typically the first ten digits on the MICR line), 2) the customer account number 



at the bank which is to be debited against (typically the next eight digits on the 
MICR line), and 3) the check number (typically the next four digits on the MICR 
line). The check number is an optional field on the MICR line 110, but is 
typically included on personal checks. 

(00261 For business checks, there also exists an Auxiliary Onus Field on the 
MICR line, which is typically the first field of the MICR line. The Auxiliary 
Onus Field typically includes the check number for a business check. 
[0027] The MICR line has space for an additional 6 digits (more if the check 
number field is not utilized), whereby this space is currently not utilized on most 
if not all conventional checks. The present invention makes use of this additional 
space on the MICR line in order to provide a hash value (preferably 6 digits, but 
may be of lesser size, such as three to five digits, and may alternatively be of 
greater size if the MICR line has the available space for it) to be used in check 
verification. 

[0028] In the present invention, each check presented for payment, either directly 
at a point of sale (POS) location or via indirectly an on-line (e.g. , Internet) 
transaction, is uniquely identified by a one-way hash value, which is computed 
using a hashing algorithm, such as a Cryptographic Hash Algorithm (CHA). The 
algorithmic techniques employed by the CHA are well known to those skilled in 



the art. Of course, other types of hashing algorithms may be utiUzed in order to 
provide a unique one-way hash value for each check, in accordance with the 
teachings of the present invention. 

[0029] In the first embodiment of the invention, the one-way hash value is 
computed from raw data that includes the ABA number, the customer account 
number, the check number (if included on the MICR line), the personal customer 
information (hereinafter referred to as the private data), and a "shared secret" 
(optional data used in the third embodiment). The personal customer information 
may be, for example, the last four digits of a checkholder's drivers license 
number or the last four digits of the checkholder's social security number. 
Preferably, it is a sequence of digits that can be readily remembered by the 
customer. One of ordinary skill in the art will recognize that the personal 
customer information may be any number of digits, such as 3, 4, 5 or 6. 
[0030] For business checks, the information may be provided to the bearer of the 
check by an employee of the business, so that the bearer can then provide the 
private (to the business) information when the check is presented to a bank (or a 
merchant) for payment. 

[0031] In the second embodiment of the invention, the n-digit hash value is 
computed based also on a 1 -digit product code (or other sized product code, such 



as a 2-digit or 3 -digit product code in alternative configurations, as will be 
recognized by those skilled in the art), which is included on the MICR line in the 
second embodiment to provide additional information to the retail POS (or other 
entity that is being presented the check for payment or for cashing). 
[0032] The MICR line information and the computed hash value, but not the 
private data of the customer or the key, is printed on the MICR line by a check 
printer when the check is created. The bank where the customer has an account 
supplies the information needed to generate the hash value to the check printer. 
When a check created in this manner is presented for payment, this information 
is obtained at the retail POS by a MICR scanner that is used to scan the check at 
the retail POS. The customer provides the private data at a retail POS, for 
example, by presenting his or her driver's license (or by verbally providing the 
private data) to a cashier (as explained above, for a business check, the 
checkholder is provided the private data from an employee of the business that 
has access to the private data). This information is keyed in at the checkout 
counter by the cashier (or by the customer, if a data entry pad for the customer is 
provided) and added to the MICR data scanned by the MICR scanner. This data 
is sent to a verifier/guarantor that verifies the validity of the check. 



-10- 



10033] For on-line transactions, such as ones conducted over the Internet, the 
customer transmits to the e-tailer's web server the sequence of digits on the 
MICR line, including the hash digits. A verification of the check is made by a 
check verifier service provider, which computes a hash value based on tiie MICR 
line data entered in by the customer. The check verifier service provider also 
obtains the private customer data from a database that is accessible by the check 
verifier service provider. The database may be located at the check verifier 
service provider, or it may be located separate therefrom, whereby it would be 
accessible via a secure communications link (e.g., using encryption techniques). 
Based on the customer-entered MICR line data (minus the hash digits), and the 
private data of the customer obtained from a database, the check verifier service 
provider computes a hash value. If the computed hash value matches the hash 
value entered in by the customer (from the MICR line of the check presented for 
payment of the on-line transaction), then the check is verified. 
[00341 Figure 2A shows the format of a MICR line printed onto a check according 
to the first embodiment of the invention. Like the MICR line on a standard 
check, the MICR line printed onto a check according to the preferred 
embodiment of the invention has a 10-digit ABA number, a 8-digit customer 
account number, and an optional 4-digit check number (whereby all of this 
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corresponds to the standard MICR line 110 as shown in Figure 1). In addition, 
the MICR line on a check according to the first embodiment of the invention also 
includes a n-digit hash code, which is shown as a 6-digit hash code 210 in Figure 
2A. 

[00351 Figure 2B shows the format of a MICR line printed onto a check according 
to the second embodiment of the invention. Like the MICR line on a standard 
check, the MICR line printed onto a check according to the preferred 
embodiment of the invention has a 10-digit ABA number, a 8-digit customer 
account number, and an optional 4-digit check number (whereby all of this 
corresponds to the standard MICR line 110 as shown in Figure 1). In addition, 
the MICR line on a check according to the second embodiment of the invention 
•also includes a product code 215 and an n-digit hash code 210. The product code 
215 is shown as a 1 -digit field, but it may be of a larger size to hold more check- 
related information, if so desired. 

[0036] By way of the present invention, checks presented for payment of on-line 
transactions, such as purchases of goods and/or services over the Internet, can be 
verified. The hash code printed on the MICR line of the check is utilized in this 
verification process. By way of the present invention, checks that are not 
verified cannot be used for on-line transactions. 
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[0037] The present invention processes each check presented for payment of an 
on-line transaction, to provide verification for the check. The present invention 
can also be used to self-authenticate the validity of the check itself, by requiring 
that the customer also provide the private data for comparison to the 
corresponding private data of that customer which is obtained from the database 
by the check verifier service provider. 

10038] As described above, each check is uniquely identified by an m-digit one- 
way hash value, which is computed by a hash algorithm, such as CHA. The 
hash value is computed on the raw data comprised of the ABA number, a j-digit 
customer account number, a k-digit check number, a p-digit product code (used 
in the second embodiment but not in the first embodiment), and an n-digit 
personal customer information ("private data") such as the last four digits of the 
customer's driver's license number or the last four digits of the customer's social 
security number (j, k, p, and n are integer values). As explained above, this 
information, except the n-digit private data of the customer, is printed on the 
MICR line by the check printer. Also, the computed hash value is printed on the 
MICR line by the check printer. 

[0039] The bank where the customer has an account supplies the information 
needed to generate the hash value to the check printer. This information is 
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preferably transmitted by secure means, such as by using a Public Key /Private 
Key (PPK) methodology, whereby encryption of the data may also be utilized. 
This information, along with the hash value, is transmitted by the customer to the 
website at which the customer is conducting an on-line transaction. The 
customer does not enter in the private data (which is not printed on the check), 
however. The customer-entered data is sent to a check verifier/guarantor (or 
check verifier service provider) by a web server, so as to conduct a verification 
of the check. 

[0040] The present invention can also retroactively protect checks that have been 
printed without having a hash code on each check and mailed to the customer. In 
these cases, an insert card that is preferably sized to fit in a checkbook is printed 
and mailed to the customer by the check printer. The insert card lists each check 
number along with the corresponding m-digit hash code for use by the customer 
when making on-line purchases. When a customer receives a checkbook 
containing checks with the hash code already printed on them, the customer 
activates those checks by either calling a particular (e.g., 1-800) phone number 
or logs on to a particular web site (and enters in personal data to thereby activate 
the checks), in order to begin to use those checks. Likewise, when a customer 
receives an insert card, the customer has to activate the checks that the insert 
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card is associated with, before the customer can use those checks for on-line 
transactions. 

[0041] Much like a credit card situation where a customer can call a 1-800 
number to immediately have the credit card turned off in the even of loss or theft 
of the card, the customer can access a secure website or call a 1-800 number to 
have the check or a series of checks immediately canceled in the event of loss or 
theft of those checks. Upon this notification, information is forwarded to the 
check verifier service provide, which sets a flag for those checks of the customer, 
so that those checks caimot be verified under any circumstances. 
[0042] The present invention provides a way for a customer to use checks for on- 
line transactions, whereby the customer is responsible for noting (in his/her 
checkbook) the check amount and date of transaction for the on-line transaction, 
since the check will not leave flie customer's hands. In particular, an electronic 
ACH will occur as soon as the check is verified, whereby the check will pass 
through the ACH in the same manner as if it was physically presented to a brick- 
and-mortar merchant. The customer receives a notification, such as an e-mail (or 
regular mail) notification, as to the amount that was debited from his/her bank 
account due to the check being used for the on-line transaction. 
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[00431 Once a check is verified, the check verifier sets a valid/invalid flag to the 
invalid state for the corresponding check number of the customer, so that the 
verified check cannot accidentally be used again by the customer for a future on- 
line transaction or for a future transaction whereby the customer physically 
presents the check to a brick-and-mortar merchant. Initially, all checks issued to 
a customer have their valid/invalid flags set to the valid state. 
[0044] Figure 3 is a block diagram illustrating the process of creating a check 
according to the invention, from the perspective of a personal check printer. 
Figure 3 shows a computer 302, a bank 300, a personal check printer 310, a 
computer 320, and a customer 330. As a first step, the bank 300 orders checks 
from the personal check printer 310. The bank 300 sends to the personal check 
printer 310 the MICR line data, which includes the ABA number of the bank 
300, the customer account number, the starting check number (as well as the 
number of checks to print), and the product code (which appears on the MICR 
line of a check in accordance with the second embodiment, but which is not 
included in the MICR line of a check in accordance with the first embodiment). 
The bank 300 also sends to the personal check printer 310 the private data of die 
customer 330, as well as check style information. For a business check, the 
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private data is "private' to the business, and is typically provided to the 
checkholder by an authorized employee of the business. 

[0045] In a second step, the computer 320, which is to execute the CHA algorithm 
(to be described in detail below), is passed the raw data. 
[0046] In a third step, the computer 320, which may be a computer of the check 
printer 310, generates a one-way, m-digit hash value using the CHA algorithm 
and the raw data. The raw data includes the ABA number, the customer account 
number, the check number, the product code (for use in the second embodiment 
but which is not part of the raw data of the first embodiment), and the private 
data of the customer 330. This is done for each check to be printed. 
100471 In a fourth step, the ABA number, the account number, the check number, 
the product code (for the second embodiment), and the hash code value are 
printed on the MICR line of each check printed by the check printer 310. The 
printed checkbooks are preferably mailed to the customer 330. 
I0048I In the case where checks already have previously been printed and mailed 
to the customer 330 without having hash codes on them, the check printer 310 
prints an insert card with hash codes for each check that does not have the hash 
codes printed on the MICR line, whereby the insert card is sent to the customer 
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330. The use of the insert card will retroactively protect checks that have already 

been previously printed and mailed to the customer 330. 

[0049] In a fifth step, upon receiving the checkbook or the insert card, the 

customer activates the checks, such as by calling a particular phone number 

(e.g., a 1-800 number) or by accessing a particular Internet website (e.g., 

www.payformance.com) and entering pertinent data (e.g., the private data of the 

customer), so as to be able to use the checks for on-line purchases. 

[0050] A third embodiment of the invention utilizes a key-generating computer 

302, which communicates with the bank 300, as shown in Figure 3. 

[00511 In the third embodiment, the computer 302 generates a key, which is 

preferably a Paybond™ shared secret (to be described in more detail below), and 

provides that shared secret to the bank 300 via communications path 304(e.g., via 

mail, via the Internet, via a telephone connection, via a Wide Area Network or 

WAN). The Paybond™ shared secret is generated at the computer 302 by a 

cryptographic message digest algorithm, such as the MD5 algorithm or some 

other suitable digest algorithm. The MD5 Algorithm is known to those skilled in 

the art, and is described, for example, in " Request for Comments 1321: The 

MD5 Message-Digest Algorithm" , which can be obtained at 

http : //www . cis . ohio-state . edu/cgi-bin/rfc/rfc 1 32 1 .html . 
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[0052] An important aspect of the invention is the providing of a one-way hash 
value on each check that is used for check verification and authentication. One- 
way hashes are utilized in communication systems to prevent what can be thought 
of as the "digital cloning" of data. One-way hashing is a process whereby a 
unique fixed length hash value is mathematically generated from the original data 
of arbitrary length. One-way hashes mathematically ensure that the 
transformation that produced the unique hash value cannot be used in a reverse 
process. In addition, a small change in the raw data used to generate the hash 
results in a change in the hash value (which may be a substantial change, 
depending on the algorithm used and the numbers input to the algorithm), which 
can then be used to determine that a check presented for payment is or is not 
fraudulent. 

[00531 Figure 4 is a diagram that illustrates the generation and transmittance of 
the Paybond™ shared secret from the computer 302 to the check printer 310 (by 
way of the bank 300), in accordance with the third embodiment. In a first step 
456, a 128-bit shared secret (the Paybond™ shared secret) is generated by a 
message digest algorithm, such as MD5. The generation of the Paybond™ shared 
secret is done by the computer 302, which can be a computer owned and 
operated by the bank 300 or which can be a computer owned and operated by a 
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service (e.g., Payformance Corporation) separate from the bank 300. In order to 
generate the 128-bit shared secret, the MD5 algorithm is applied to some 
arbitrary data (such as a data file). The MD5 algorithm then creates a 128-bit 
digest (hash) which is used as the shared secret. 

[0054] The 128-bit shared secret is transmitted between the bank 300 and the 
check printer 310 and between the bank 300 and a check verifier service provider 
in encrypted form by using a secure transmission procedure, such as by using a 
Public/Private Key (PPK) algorithm or other type of secure 
transmission/reception scheme. An alternative approach may be to use the 
Diffie-Helman Key Exchange Algorithm. Both die PPK algorithm and the Diffie- 
Helman Key Exchange Algorithm are known to those skilled in the art. 
[0055] A 1024-bit public/private key pair is generated at both the check printer 
310 and the check verifier service provider using the PPK algorithm. If a 
different algorithm is used, the size of the key pair may be different than that 
given above. 

[oosGi The bank 300 is provided with the public key of both the check printer 300 
and the check verifier service provider, while the corresponding private keys are 
known only to the check printer 310 and the check verifier service provider, 
respectively. 
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10057] The 128-bit shared secret generated by the MD5 algorithm is encrypted 
using the public key of the check printer 310 and transmitted to the check printer 
310. Also, the 128-bit shared secret generated by the MD5 algorithm is 
encrypted using the public key of the check verifier service provider and 
transmitted to the check verifier service provider. This encryption is shown by 
step 469 in Figure 4. 

10058] In step 476, the check printer 310 (or the check verifier service provider) 
then decrypts the 128-bit shared secret at its end using its private key (e.g. , its 
private key). No other entity can decrypt the 128-bit shared secret because only 
the check printer 310 (or the check verifier service provider) has access to its 
private key. The 128-bit shared secret serves as an input to the Cryptographic 
Hash Algorithm (CHA), which is shown as step 486. 

[0059] Figure 5 is a flow chart illustrating the actual computation of a one-way 
hash value by use of CHA. CHA is a well-known hashing algorithm, whereby 
public information on this hash algorithm may be obtained from the Internet, for 
example. Steps 502, 503 and 504 of Figure 5 are utilized in the third 
embodiment of the invention, but not in the first and second embodiments of the 
invention (which start their CHA procedure with step 510). 
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[0060] In step 502, the 128-bit shared secret is input to the computer performing 
the CHA. 

100611 In step 503, a SHA-1 hash algorithm is performed on the 128-bit shared 
secret. SHA-1 is well known to those skilled in the art, and is described, for 
example, in "Secure Hash Standard", dated April 17, 1995, which is obtainable 
from the Internet. Of course, other types of hash algorithms besides SHA-1 may 
be performed, while remaining within the scope of the invention. 
10062] As a result of the SHA-1 algorithm performed on the 128-bit Paybond™ 
shared secret, a 160-bit hash value is obtained in step 504. 
[0063] In step 510, the ABA number, the customer account number, the check 
numbers to-be-printed (or just the starting check number and the total number of 
checks to be printed), and the private data of the customer (for a personal check, 
whereby private data of a business would be provided for a business check), are 
provided to the check printer 310 by the bank 300 in the first embodiment. For 
the second embodiment, the product code data is also provided to the check 
printer 310. 

10064] In step 520, the check printer 310 accumulates the data obtained from step 
510 and the 160-bit hash value of the Paybond™ shared secret obtained from step 
504 (for the third embodiment that uses the key), so that the accumulated data 
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will be subject to CHA. The data obtained from step 510 may be provided to the 
check printer 310 by an Internet connection, a WAN, or via the mail, for 
example. The raw data accumulated in step 520 is preferably stored in a byte 
array, in a memory (e.g., RAM), at the check printer 310, and is passed to the 
computer 320 for computing the hash value for the checks to be printed. 
[0065] In a step 530, a determination is made as to whether or not all of the 
required data sent to computer 320 by the check printer 310 has been 
accumulated in byte form (or other type of digital form) by the computer 320. If 
no, the process returns to step 520, to wait for the remaining data. If yes, the 
process moves to step 540. 

[00681 At step 540, an error check computation is performed, which is shown as a 
CRC-32 computation in Figure 5. Such an error check computation is well 
known to those skilled in the art. In the present invention, other types of 
computations may be performed, other than the CRC-32 computation, to provide 
the requisite number of hash bits. 

[0067] At step 550, as a result of the CRC-32 computation at step 540, a 32-bit 
hash value is generated. Of course, if a different error check computation is 
performed, a hash value having a different number of bits (e.g., 24 bits, 64 bits) 
may be obtained at step 550. 
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[0068] At Step 560, the 32-bit hash value is decreased in size to obtain a 16-bit 
hash value. In preferred embodiments of the present invention, the two least 
significant bytes of the 32-bit hash value are exclusive-or'ed with the two most 
significant bytes of the 32-bit hash value, in order to obtain a 16-bit hash value. 
Other ways of decreasing the hash size may be contemplated, such as by 
exclusive-nor'ing the two least significant bytes and the two most significant 
bytes with each other, for example. 

[00691 At step 570, the 16-bit hash value obtained as an output of step 460 is 
mapped to an n-digit hash value (for example, a 6-digit hash value, so as to be of 
a size that can be printed onto a MICR line of a check). The mapping for doing 
this may be by way of a table lookup procedure, such as by converting the 16-bit 
hash value to its decimal equivalent. For example, 1010111001010001 hash 
value may be mapped to 127121, by taking each triplet of bits, starting from the 
least significant bit and working up to the most significant bit, and mapping each 
triplet of bits to a decimal value. Other ways of mapping from 16-bits to n-digits 
(where n equals 6 digits for this example) may be contemplated, while remaining 
within the scope of the invention as described herein. For example, the triplets 
may be started at the most significant bit, working down to the least significant 
bit (whereby the last-triplet of bits corresponds to the least significant bit only, as 
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converted to a decimal value). In that case, the computed value would be 
534501. 

[0070] At step 580, an n-digit (for example, a 6-digit) hash value is obtained, 
which is provided to the check printer 310 by the computer 320, for printing on 
each check. The n-digit (for example, the 6-digit) hash value will be a unique, 
non-deterministic value for each check to be printed by the check printer 310, 
since the check number (if included on the MICR line) is different for each 
check. 

10071] Figure 6 illustrates the elements involved in the interaction between the 
customer 330, a web site 606 of an e-tailer, an on-line web server 610 (that 
stores die information of the e-tailer 's web site 606 accessed by the customer 
330), a check verifier service provider 620, and a server computer 630. 
[0072] The check verifier service provider 620 may be any one of currently 
available check verifier service providers, or a new provider of such a service. 
For example, Telecheck"™ currently provides such a service, and it could be 
utilized as part of the check verification service of the present invention, whereby 
it's software would have to be modified in order to compute hash codes in a 
check verification process, in accordance with the present invention. 
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[0073] In a first step, the customer 330 selects goods or services for purchase at 
the on-line web site 606 (e.g., purchase books at Amazon.com). The customer 
330 then keys in (by way of his/her computer keyboard) the ABA number, 
account number, check number and product code (if included on die check as in 
accordance with the second embodiment) printed on the MICR line of his/her 
check. The customer 330 also keys in the m-digit hash code (for example, the 6- 
digit hash code generated by the CHA algorithm) for that check by looking it up 
on the MICR line of the check or by looking it up on the insert card provided to 
the customer by the check printer (see Figure 8, which shows an insert card 810 
that has a column 820 with hash codes and a column 830 with corresponding 
check numbers). For ease in doing this, the customer may be provided with a 
template from either the bank or from the check printer, which can be placed 
over the check to provide clear indications to the customer 330 as to which values 
on the MICR line correspond to which information. 

[0074] Figure 9 shows a template 910 which may be utilized with the present 
invention. The template 910 is sized the same as a check, and has openings 920 
for the ABA number, the customer account number, the check number, the 
product code, and the hash code value for a check printed in accordance with the 
present invention. When the template 910 is placed directly over a check, the 
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corresponding data on the MICR line appears, so that the customer can determine 
which data corresponds to which information to be entered on-line via a computer 
keyboard or the like, when conducting an on-line transaction in accordance with 
the present invention. 

[0075] In a second step, the data keyed in by the customer 330 is transferred to 
the on-line web site 606 via an Internet connection and thereby provided to the 
on-line web server 610, which reads and processes information sent to the on-line 
web site 606. 

[0076] In a third step, the on-line web server 610 transmits the hash code and 
other data keyed in by the customer 330 over a network 677 (for example, this 
network may be a Virmal Private Network, VPN, or the Internet) to the check 
verifier service provider 620. 

[0077] In a fourth step, the server computer 630 (of the check verifier service 
provider, in a preferred implementation) computes a one-way hash using the 
CHA, using the data keyed in by the customer 330 and the customer's private 
data that is obtained from a database accessible by the server computer 630. For 
the third embodiment, a shared secret previously obtained by the check verifier 
service provider 620 (where that shared secret value is assigned to the customer 
or account corresponding to the check presented for verification) is used in the 
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computation of the hash value by the check verifier service provider 620. For 
the first and second embodiments, a shared secret value is not utilized in the hash 
value computation process. 

[0078] In a fifth step, if the computed hash value matches the hash value keyed in 
by the customer 330, the transaction is approved, and the check verifier service 
provider 620 responds with a transaction approval code. If the hash values do 
not match, then a transaction disapproval code is output by the check verifier 
service provider 620. 

[0079] In a sixth step, the transaction approval code or transaction disapproval 
code is returned to the on-line web server 610 (via the network 677), whereby 
the on-line web server 610 updates the e-tailer's web site 606 accordingly. The 
customer 330 is notified as to whether his/her check has been approved or 
disapproved, via the Internet (that is, it may be the same network as network 677 
in Figure 6). 

[0080] In a fourth embodiment, the e-tailer may require that the customer 330 
enter in his/her private data (for example, the last 4 digits of his/her driver's 
license or social security number) along with the data listed in the first step 
described above. This will enable the check verifier service provider 620 to 
verify not only the check itself but also authenticate the identity of the customer 
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330. As an incentive for doing this, the e-tailer may choose to offer free 
shipping to the user who provides his/her private data on-line, for example. 
100811 In the second embodiment, a product code field is also included on the 
MICR line. The product code is a field of digits (e.g. , 1 or 2 digit field, for 
example) that conveys more information on the check and the account on which 
the check is to be drawn against. For example, Product Code = 0 signifies that 
the account in question is not sufficient funds (NSF) protected, Product Code = 
1 signifies that the check is. authorized up to a maximum of $1 ,000, Product 
Code == 2 signifies that the check is authorized up to a maximum of $10,000, and 
Product Code = 4 signifies the type of data required (e.g., social security 
number, or driver's license number). 

[0082] The check verifier service provider 620 is also provided with the amount 
of the on-line transaction subject to verification, and uses the information in the 
product code field when determining whether or not to authorize the check for 
the on-line transaction. In the first embodiment, whereby product code data is 
not used in the check verification, the e-tailer determines on its own whether or 
not to authorize a "verified" check for a particular dollar amount. 
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[0083] The providing of the check authorized/not authorized information and/or 
the (decoded) product code information is shown by way of communications path 
685 in Figure 6, which is sent over Network 677. 

[0084] Figure 7 illustrates the check verification process for the various described 
embodiments of the invention from the perspective of the check verifier service 
provider 620. 

[0085] hi a first step, the e-tailer 710 transmits the data keyed in by the customer 
330 which is received by the e-tailer 710 from its on-line web server (see Figure 
6, for example), to the check verifier service provider 620, as shown by 
communications path 705. This transmission of data is made over Network 677 
(e.g., Internet, a WAN, etc.). The program that implements the CHA algorithm 
(or other type of hashing algorithm used) is preferably stored in memory that is 
accessible by the check verifier computer 630. 

[0086] The raw data is passed to the check verifier computer 630 from the check 
verifier service provider 620, as shown by communications path 715. 
[0087] The check verifier computer 630 uses the raw data comprising the ABA 
number, the customer account number, the check number (if included as part of 
the MICR line), the private data of the customer (or the private data of a business 
for a business check) as obtained from a database accessible by the check verifier 
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computer 630. The PayBond™ shared secret (which the check verifier service 
provider 620 has previously received from the bank 300) is also provided in the 
third embodiment. The check verifier service provider 620 generates the one- 
way hash value using this data and the executable code stored in its memory. It 
then compares the computed hash value with the hash value transmitted by the e- 
tailer (transmitted to the e-tailer's web server via an Internet connection) to the 
check verifier service provider 620. If there is a match, the check is verified. 
The status of the check is retumed to the check verifier service provider 620, as 
shown by communications path 725 . In addition, die check verifier computer 
630 also maintains a list of check numbers which have been presented for 
payment and hence prevents the reuse of check numbers. 

[00881 The check verifier service provider 620 then returns the stams of the check 
verification process along with the message appropriate to the product code to the 
retail e-tailer, as shown by communications path 735. This passage of data is 
made over Network 677. As explained earlier, other information besides check 
authorized/not-authorized, such as a specific dollar cap for the check, whether 
the check is NSF or overdraft protected, etc., may be provided as well to the e- 
tailer, based on the information in the product code field that is included on the 
MICR line in the second embodiment. Based on the information provided to it 
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from the check verifier service provider 620, the e-tailer 710 either accepts the 
check or rejects the check. 

[008$] Thus, a system and method has been described according to several 
embodiments of the present invention. Many modifications and variations may 
be made to the techniques and structures described and illustrated herein without 
departing from the spirit and scope of the invention. Accordingly, it should be 
understood that the methods and apparatus described herein are illustrative only 
and are not limiting upon the scope of the invention. 

[0090] For example, the location of the hash code (and the product code in the 
second embodiment) on the MICR line may be different from that shown in 
Figures 2A and 2B. For example, the hash code would typically be provided on 
the right side of the MICR line (next to check number) for a personal check, and 
the hash code would typically be provided on the left side of the MICR line (next 
to ABA number) for a business check. This placement of the hash code on the 
MICR line is based on the current specifications for the MICR line, and may be 
changed to include other locations if the MICR line specifications are modified in 
the future. 

[0091] Additionally, while the present invention has been described with respect 
to personal checks and business checks, it is also applicable to other modes of 
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payment, such as traveler's checks, money orders, or cashier's checks, which 
may be presented for payment of an on-line transaction. 

10092] It is envisioned that the fee for providing such checks with hash values and 
for verifying such checks with hash values will be less than the amount currently 
charged by credit card companies for authorizing credit cards. For example, a 
0.9% fee per transaction may be assessed, which makes such a system and 
method attractive to e-tailers and to banks. 
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